<spacer width=16 height=1>C++'s new exception-handling features enable the
programmer to remove the error-handling code from
the "main line" of a program's execution. This
improves program readability and modifiability. <br>
<spacer width=16 height=1>With the C++ style of exception handling it is possible
to catch all kinds of exceptions, to catch all exceptions
of a certain type or to catch all exceptions of related
types. This makes programs more robust by reducing
the likelihood that errors will not be caught by a
program. Exception handling is provided to enable
programs to catch and handle errors rather than letting <br>
</page>
<page>
them occur and suffering the consequences. If the
programmer does not provide a means of handling a
fatal error, the program terminates.<br>
<spacer width=16 height=1>Exception handling is designed for dealing with
<i>synchronous errors</i> such as an attempt to divide by zero
(that occurs as the program executes the divide
instruction). With exception handling, before the
program executes the division, it checks the
denominator and "throws" (issues) an exception if the
denominator is zero. <br>
<spacer width=16 height=1>Exception handling is not designed to deal with
asynchronous situations such as disk I/O completions,
network message arrivals, mouse clicks, and the like; <br>
</page>
<page>
these are best handled through other means, such as
interrupt processing.<br>
<spacer width=16 height=1>Exception handling is used in situations in which the
system can recover from the error causing the
exception. The recovery procedure is called an
<i>exception handler</i>.<br>
<spacer width=16 height=1><a href="^Practice::c:s0p1"><img src="bckgrnds/icons/gpp_ico.gif" align=sidebar></a>Exception handling is typically used in situations in
which the error will be dealt with by a different part of
the program (i.e., a different scope) from that which
detected the error. <a href="^Practice::c:s0p0"><img src="bckgrnds/icons/gpp_ico.gif" align=sidebar></a>A program that carries on an
interactive dialog with a user should not use exceptions
to process input errors.<br>
</page>
<page>
Exception handling is especially appropriate for
situations in which the program will not be able to
recover, but needs to provide orderly cleanup, then shut
down "gracefully."<br>
<spacer width=16 height=1><a href="^Engineer::c:s0p0"><img src="bckgrnds/icons/seo_ico.gif" align=sidebar></a>There is another reason to avoid using exception
handling techniques for conventional program control.
<a href="^Errors::c:s0p0"><img src="bckgrnds/icons/cpe_ico.gif" align=sidebar></a>Exception handling is designed for error processing
which is an infrequent activity that is often used
because a program is about to terminate. Given this, it
is not required that C++ compiler writers implement
exception handling for the kind of <a href="^Perform::c:s0p2"><img src="bckgrnds/icons/perf_ico.gif" align=sidebar></a>optimal performance
<a href="^Perform::c:s0p0"><img src="bckgrnds/icons/perf_ico.gif" align=sidebar></a>that might be expected of regular application code.<br>
</page>
<page>
Exception handling helps improve a program's fault
tolerance. It becomes "more pleasant" to write error-
processing code, so programmers are more likely to
provide it. It also becomes possible to catch exceptions
in a variety of ways such as by type, or even to specify
that exceptions of any type are to be caught. <br>
<spacer width=16 height=1>The majority of programs written today support only a
single thread of execution. Multithreading is receiving
great attention in recent operating systems like
Windows NT, OS/2, and various versions of UNIX. The
techniques discussed in this chapter apply even for
multithreaded programs, although we do not discuss
multithreaded programs specifically.<br>
</page>
<page>
We will show how to deal with "uncaught" exceptions.
We will consider how unexpected exceptions are
handled. We will show how related exceptions can be
represented by exception classes derived from a
common base exception class.<br>
<spacer width=16 height=1>The exception-handling features of C++ are becoming
widely used as a result of the ANSI C++
standardization effort. <a href="^Engineer::c:s0p1"><img src="bckgrnds/icons/seo_ico.gif" align=sidebar></a>Standardization is especially
important on large software projects where dozens or
even hundreds of people work on separate components
of a system and these components need to interact for
the overall system to function properly.<br>
</page>
<page>
Exception handling can be viewed as another means of
returning control from a function or exiting a block of
code. Normally, when an exception occurs, it will be
handled by a caller of the function generating the
exception, by a caller of that caller, or however far back
in the call chain it becomes necessary to go to find a
handler for that exception. <br>
</page>
<page>
<b>Select the true statement(s). </b><br>
<component type="checkbox" width=20 height=18 label="" name="" feedback="False. Exception handling is designed for synchronous errors.">
Exception handling is designed for asynchronous errors. <br>
If the programmer does not provide the means of handling an exception, the program terminates. <br>
<component type=button name=b label="Check Your Answer" width=125 height=24>
</page>
</section>
<section type=Body name=Default title="13.2 When Exception Handling Should Be Used">
<page>
<font size=18 bold>13.2 When Exception Handling Should Be
Used</font><hr>
<a href="^Practice::c:s0p2"><img src="bckgrnds/icons/gpp_ico.gif" align=sidebar></a>Exception handling should be used to process only
exceptional situations, despite the fact that there is
nothing to prevent the programmer from using
exceptions as an alternate for program control; to
process exceptions for program components that are not
geared to handling those exceptions directly; to process
exceptions from software components such as
functions, <a href="^Engineer::c:s0p3"><img src="bckgrnds/icons/seo_ico.gif" align=sidebar></a>libraries, and classes that are likely to be
widely used, and where it does not make sense for those
components to handle their own exceptions; on large <br>
</page>
<page>
projects to handle error processing in a uniform manner
project wide. <br>
</page>
</section>
<section type=Body name=Default title="13.3 Other Error-Handling Techniques">
<page>
<font size=18 bold>13.3 Other Error-Handling Techniques</font><hr>
We have presented a variety of ways of dealing with
exceptional situations prior to this chapter. The
following summarizes these and other useful
techniques.<br>
<indent width=8 delay>* Use <b>assert</b> to test for coding and design errors. If an
assertion is <b>false</b>, the program terminates and the code
must be corrected. This is useful at debugging time.</indent>
<indent width=8 delay>* Simply ignore the exceptions. This would be devastating for software products released to the general public, or for special-purpose software needed for mission-
critical situations. But for your own software developed </indent>
</page>
<page>
<indent width=8 delay>* for your own purposes, it is quite common to ignore
many kinds of errors.</indent>
<indent width=8 delay>* Abort the program. This, of course, prevents a program from running to completion and producing incorrect results. Actually, for many types of errors this is a
good strategy, especially for nonfatal errors that enable
a program to run to completion, perhaps misleading the
programmer to think that the program functioned correctly. Here, too, such a strategy is inappropriate for
mission-critical applications. <a href="^Errors::c:s0p2"><img src="bckgrnds/icons/cpe_ico.gif" align=sidebar></a>Resource issues are also
important here. If a program obtains a resource, the program should normally return that resource before program termination. </indent>
</page>
<page>
<indent width=8 delay>* Set some error indicator. The problem with this is
that programs may not check these error indicators at all
points at which the errors could be troublesome.</indent>
<indent width=8 delay>* Test for the error condition, issue an error message,
and call <b>exit</b> to pass an appropriate error code to the
program's environment.</indent>
<indent width=8 delay>* <b>setjump</b> and <b>longjump</b>. These capabilities, available
through <b><setjmp.h></b> enable the programmer to specify
an immediate jump out of deeply nested function calls
back to an error handler. Without <b>setjump</b>/<b>longjump</b>, a
program must execute several returns to get out of the
deeply nested function calls. These could certainly be
used to jump to some error handler. But they are dan</indent>
</page>
<page>
<indent width=8 delay>* gerous in C++ because they unwind the stack without
calling destructors for automatic objects. This can lead
to serious problems.</indent>
<indent width=8 delay>* Certain specific kinds of errors have dedicated capabilities for handling them. For example, when <b>new</b> fails
to allocate memory, it can cause a <b>new_handler</b> function to execute to deal with the error. This function can
be varied by supplying a function name as the argument
to <b>set_new_handler</b>. We discuss function
<b>set_new_handler</b> in detail in<a href="#s14p0"> Section 13.14</a>.</indent>
</page>
</section>
<section type=Body name=Default title="13.4 Basics of C++ Exception Handling: try, throw, catch">
<page>
<font size=18 bold>13.4 Basics of C++ Exception Handling: <tt>try</tt>,
<tt>throw</tt>, <tt>catch
</tt></font><hr>
C++ exception handling is geared to situations in which
the function that detects an error is unable to deal with
it. Such a function will <b><i>throw</i></b> <i>an exception</i>. There is no
guarantee that there will be "anything out there"--i.e.,
an <i>exception handler</i> specifically geared to processing
that kind of exception. If there is, the exception will be
<i>caught</i> and <i>handled</i>. If there is no exception handler for
that particular kind of exception, the program
terminates.<br>
</page>
<page>
The programmer encloses in a <b><i>try block</i></b> the code that
may generate an error that will produce an exception.
The <b>try</b> block is followed by one or more <b><i>catch blocks</i></b>.
Each <b>catch</b> block specifies the type of exception it can
catch and handle. Each <b>catch</b> block contains an
exception handler. If the exception matches the type of
the parameter in one of the <b>catch</b> blocks, the code for
that <b>catch</b> block is executed. Otherwise, the exception
mechanism looks for an exception handler in any
enclosing <b>try</b> block. If no handler is found, function
<b>terminate</b> is called, which by default calls function
<b>abort</b>.<br>
</page>
<page>
Program control on a thrown exception leaves the <b>try</b>
block and searches the <b>catch</b> blocks in order for an
appropriate handler (we will soon discuss what makes a
handler "appropriate"). If no exceptions are thrown in
the <b>try</b> block, the exception handlers for that block are
skipped and the program resumes execution after the
last <b>catch</b> block.<br>
<spacer width=16 height=1>We can specify the exceptions a function <b>throw</b>s. As an
option, we can specify that a function shall not <b>throw</b>
any exceptions at all.<br>
<spacer width=16 height=1><a href="^Engineer::c:s0p5"><img src="bckgrnds/icons/seo_ico.gif" align=sidebar></a>The exception is thrown in a <b>try</b> block in the function,
or the exception is thrown from a function called
directly or indirectly from the <b>try</b> block. The point at <br>
</page>
<page>
which the <b>throw</b> is executed is called the <b><i>throw point</i></b>.
This term is also used to describe the <b>throw</b> expression
itself. Once an exception is thrown, control cannot
return to the <b>throw</b> point.<br>
<spacer width=16 height=1>When an exception occurs, it is possible to
communicate information to the exception handler from
the point of the exception. That information is the type
of the thrown object itself or information placed into
the thrown object.<br>
<spacer width=16 height=1>The thrown object is typically a character string (for an
error message) or a class object. The thrown object
conveys information to the exception handler that will
process that exception. <br>
</page>
<page>
<b>Select the true statement(s). </b><br>
<component type="checkbox" width=20 height=18 label="" name="" feedback="False. Any number of catch blocks may follow a try.">
A try block can be followed with at most two catch blocks. <br>
The thrown object conveys information to the exception handler that will process that exception. <br>
<component type=button name=b label="Check Your Answer" width=125 height=24>
</page>
</section>
<section type=Body name=Default title="13.5 A Simple Exception-Handling Example: Divide by Zero">
<page>
<font size=18 bold>13.5 A Simple Exception-Handling Example: Divide by Zero</font><hr>
Now let us consider a simple example of exception
handling. The program of<a href="^Code::c:s0p0"> <img src="bckgrnds/icons/code_ico.gif" align=sidebar>Fig. 13.1</a> uses <b>try</b>, <b>throw</b> and
<b>catch</b> to detect a division by zero, indicate a divide-by-
zero exception and handle a divide-by-zero exception.<br>
<spacer width=16 height=1>The first output window shows a successful execution.
In the second, a zero denominator is entered and the
program detects the error and issues an error message.<br>
<spacer width=16 height=1>Now consider the driver program in <b>main</b>. The program
prompts for, and inputs, two integers. Note the
"localized" declaration of <b>number1</b> and <b>number2</b>. <br>
</page>
<page>
Next, the program proceeds with a <b>try</b> block which
wraps the code that may <b>throw</b> an exception. Note that
the actual division that may cause the error is not
explicitly listed inside the <b>try</b> block. Rather, the call to
function <b>quotient</b> invokes the code that attempts the
actual division. Function <b>quotient</b> actually <b>throw</b>s the
divide-by-zero exception object as we will see
momentarily. In general, errors may surface through
explicitly mentioned code in the <b>try</b> block, through
calls to a function, or even through deeply nested
function calls initiated by code in the <b>try</b> block. <br>
<spacer width=16 height=1>The <b>try</b> block is immediately followed by a <b>catch</b> block
containing the exception handler for the divide-by-zero <br>
</page>
<page>
error. In general, when an exception is thrown within a
<b>try</b> block, the exception is caught by a <b>catch</b> block that
specifies the appropriate type that matches the thrown
exception. In <a href="^Code::c:s0p0"><img src="bckgrnds/icons/code_ico.gif" align=sidebar>Fig. 13.1</a>, the <b>catch</b> block specifies that it
will catch exception objects of type
<b>DivideByZeroException</b>; this type matches the type of
the object thrown in function <b>quotient</b>. The body of this
exception handler issues an error message and returns,
in this case with 1 indicating termination because of an
error. Exception handlers can be much more elaborate
than this. <br>
<spacer width=16 height=1>If, when executed, the code in a <b>try</b> block does not
<b>throw</b> an exception, then all the <b>catch</b> handlers <br>
</page>
<page>
immediately following the <b>try</b> block are skipped and
execution resumes with the first line of code after the
<b>catch</b> handlers; in<a href="^Code::c:s0p0"> <img src="bckgrnds/icons/code_ico.gif" align=sidebar>Fig. 13.1</a> a <b>return</b> statement is
executed that returns 0, indicating normal termination.<br>
<spacer width=16 height=1>Now let us examine the definitions of class
<b>DivideByZeroException</b> and function <b>quotient</b>. In
function <b>quotient</b>, when the <b>if</b> statement determines
that the denominator is zero, the body of the <b>if</b>
statement issues a <b>throw</b> statement which specifies the
name of the constructor for the exception object. This
causes an object of class <b>DivideByZeroException</b> to
be created. This object will be caught by the <b>catch</b>
statement (specifying type <b>DivideByZeroException</b>) <br>
</page>
<page>
after the <b>try</b> block. The constructor for class
<b>DivideByZeroException</b> simply points data member
<b>message</b> at the string "<b>Divide by zero</b>". The thrown
<a href="^Practice::c:s0p3"><img src="bckgrnds/icons/gpp_ico.gif" align=sidebar></a>object is received in the parameter specified in the
<b>catch</b> handler (in this case, parameter <b>error</b>), and the
message is printed there through a call to <b>public</b> access
function <b>printMessage</b>. <br>
</page>
</section>
<section type=Body name=Default title="13.6 Throwing an Exception">
<page>
<font size=18 bold>13.6 Throwing an Exception</font><hr>
The <b>throw</b> keyword is used to indicate that an
exception has occurred. This is called <i>throwing an
exception</i>. A <b>throw</b> normally specifies one operand (a
special case we will discuss specifies no operands). The
operand of a <b>throw</b> can be of any type. If the operand is
an <i><a href="^Engineer::c:s0p7"><img src="bckgrnds/icons/seo_ico.gif" align=sidebar></a></i>object, we call it an <i>exception object</i>. A conditional
expression can be thrown instead of an object. It is
possible to <b>throw</b> objects not intended for error
handling.<br>
<spacer width=16 height=1>Where is an exception caught? Upon being thrown, the
exception will be caught by the closest exception <br>
</page>
<page>
handler (for the <b>try</b> block from which the exception was
thrown) specifying an appropriate type. The exception
handlers for a <b>try</b> block are listed immediately
following the <b>try</b> block.<br>
<spacer width=16 height=1><a href="^Engineer::c:s0p9"><img src="bckgrnds/icons/seo_ico.gif" align=sidebar></a>As part of throwing an exception, a temporary copy of
the <b>throw</b> operand is created and initialized. This
temporary object then initializes the parameter in the
exception handler. The temporary object is destroyed
when the exception handler completes execution and
exits.<br>
<spacer width=16 height=1>When an exception is thrown, control exits the current
<b>try</b> block and proceeds to an appropriate <b>catch</b> handler
(if one exists) after that <b>try</b> block. It is possible that the <br>
</page>
<page>
<b>throw</b> point could be in a deeply nested scope within a
<b>try</b> block; control will still proceed to the <b>catch</b>
handler. It is also possible that the <b>throw</b> point could be
in a deeply nested function call; still, control will
proceed to the <b>catch</b> handler.<br>
<spacer width=16 height=1>A <b>try</b> block may appear to contain no error checking
and include no <b>throw</b> statements, but code referenced
in the <b>try</b> block could certainly cause error-checking
code in constructors to execute. Code in a <b>try</b> block
could perform array subscripting on an array class
object whose <b>operator[]</b> member function could be
overloaded to <b>throw</b> an exception on a subscript-out-
of-range error. Any function call can invoke code that <br>
</page>
<page>
might <b>throw</b> an exception or call another function that
<b>throw</b>s an exception.<br>
<spacer width=16 height=1><a href="^Errors::c:s0p6"><img src="bckgrnds/icons/cpe_ico.gif" align=sidebar></a>Although an exception can terminate program
execution, it is not required to terminate program
execution. However, an exception does terminate the
<a href="^Errors::c:s0p3"><img src="bckgrnds/icons/cpe_ico.gif" align=sidebar></a>block in which the exception occurred.<br>
The throw keyword is used to indicate that an exception has occured. <br>
<component type=button name=b label="Check Your Answer" width=125 height=24>
</page>
</section>
<section type=Body name=Default title="13.7 Catching an Exception">
<page>
<font size=18 bold>13.7 Catching an Exception</font><hr>
Exception handlers are contained in <b>catch</b> blocks. Each
<b>catch</b> block starts with the keyword <b>catch</b> followed by
parentheses containing a type (indicating the type of
exception this catch block handles) and an optional
parameter name. This is followed by braces delineating
the exception-handling code. When an exception is
caught, the code in the <b>catch</b> block is executed.<br>
<spacer width=16 height=1>The <b>catch</b> handler defines its own scope. A <b>catch</b>
<a href="^Errors::c:s0p7"><img src="bckgrnds/icons/cpe_ico.gif" align=sidebar></a>specifies in parentheses the type of the object to be
caught. The parameter in a <b>catch</b> handler can be named
or unnamed. If the parameter is named, the parameter <br>
</page>
<page>
can be referenced in the handler. If the parameter is
unnamed, i.e., only a type is listed for purposes of
matching with the thrown object type, then information
is not conveyed from the <b>throw</b> point to the handler;
only control passes from the <b>throw</b> point to the handler.
For many exceptions, this is acceptable.<br>
<spacer width=16 height=1>An exception whose thrown object's type matches the
type of the argument in the <b>catch</b> header causes the
<b>catch</b> block, i.e., the exception handler for exceptions
of that type, to execute.<br>
<spacer width=16 height=1>The <b>catch</b> handler that catches an exception is the first
one listed after the currently active <b>try</b> block that <br>
</page>
<page>
matches the type of the thrown object. The matching
rules are discussed shortly.<br>
<spacer width=16 height=1><a href="^Errors::c:s0p8"><img src="bckgrnds/icons/cpe_ico.gif" align=sidebar></a>An exception that is not caught causes a call to
<b>terminate</b> which by default terminates a program by
calling <b>abort</b>. It is possible to specify customized
behavior by designating another function to be executed
by providing that function's name as the argument in a
<b>set_terminate</b> function call.<br>
<spacer width=16 height=1><a href="^Engineer::c:s0p11"><img src="bckgrnds/icons/seo_ico.gif" align=sidebar></a>A <b>catch</b> followed by parentheses enclosing an ellipsis <br>
<font size=2><br></font><font size=11><pre>
catch( ... )<p>
</pre></font>
means to catch all exceptions. <br>
<spacer width=16 height=1>It is possible that no handler will match a particular
thrown object. This causes the search for a match to <br>
</page>
<page>
continue in the next enclosing <b>try</b> block. As this
process continues, it may eventually be determined that
there is no handler in the program that matches the type
of the thrown object; in this case function <b>terminate</b> is
called, which by default calls function <b>abort</b>. <br>
<spacer width=16 height=1>The exception handlers are searched in order for an
appropriate match. The first handler that yields a match
is executed. When that handler finishes executing,
control resumes with the first statement after the last
<b>catch</b> block, i.e., the first statement after the last
exception handler for that <b>try</b> block.<br>
<spacer width=16 height=1>It is possible that several exception handlers will
provide an acceptable match to the type of the <br>
</page>
<page>
exception that was thrown. In this case, the first
exception handler that matches the exception type is
executed. If several handlers match, and if each of these
handles the exception differently, then the <a href="^Debug::c:s0p0"><img src="bckgrnds/icons/dbt_ico.gif" align=sidebar></a>order of the
handlers will affect the manner in which the exception
is handled.<br>
<spacer width=16 height=1>It is possible that several <b>catch</b> handlers could contain a
class type that would match the type of a particular
thrown object. This can happen for several reasons.
First, there can be a "catch-all" handler <b>catch(...)</b> that
will catch any exception. <a href="^Errors::c:s0p9"><img src="bckgrnds/icons/cpe_ico.gif" align=sidebar></a>Second, because of
inheritance hierarchies, it is possible that a derived-
class object can be caught either by a handler specifying <br>
</page>
<page>
the derived-class type, or by handlers specifying the
types of any base classes of that derived class.<br>
<spacer width=16 height=1>Sometimes a program may process many closely
related types of exceptions. Instead of providing
separate exception classes and <b>catch</b> handlers for each,
a programmer can provide a single exception class and
<b>catch</b> handler for a group of exceptions. As each
exception occurs, the exception object can be created
with different <b>private</b> data. The <b>catch</b> handler can
examine this <b>private</b> data to distinguish the type of the
exception.<br>
</page>
<page>
When does a match occur? The type of the <b>catch</b>
handler parameter matches the type of the thrown
object if<br>
<indent width=8 delay>* they are indeed of the same type.</indent>
<indent width=8 delay>* the <b>catch</b> handler parameter type is a <b>public</b> base
class of the class of the thrown object. </indent>
<indent width=8 delay>* <a href="^Errors::c:s0p11"><img src="bckgrnds/icons/cpe_ico.gif" align=sidebar></a>the handler parameter is of a base-class pointer or
reference type and the thrown object is of a derived-
class pointer or reference type.</indent>
<indent width=8 delay>* the <b>catch</b> handler is of the form <b>catch( ... )</b>.</indent>
An exact type match is required,. No promotions or
conversions are performed when looking for a handler
except for derived-class-to-base-class conversions.<br>
</page>
<page>
It is possible to <b>throw</b> <b>const</b> objects. In this case, the
<b>catch</b> handler argument type must also be declared
<b>const</b>.<br>
<spacer width=16 height=1>By default, if no handler is found for an exception, the
program terminates. Although this may seem like the
right thing to do, it is not what programmers are
necessarily used to doing. Rather, errors often simply
happen and then program execution continues, possibly
only "hobbling" along.<br>
<spacer width=16 height=1><a href="^Errors::c:s0p13"><img src="bckgrnds/icons/cpe_ico.gif" align=sidebar></a>A <b>try</b> block followed by several <b>catche</b>s resembles a
<b>switch</b> statement. It is not necessary to use <b>break</b> to
exit an exception handler in a manner that skips over
the remaining exception handlers. Each <b>catch</b> block <br>
</page>
<page>
defines a distinct scope whereas all the cases in a
<b>switch</b> statement are contained within the scope of the
defined within its <b>try</b> block because when an exception
occurs the <b>try</b> block terminates and all the automatic
objects inside the <b>try</b> block are destroyed before the
handler begins executing.<br>
<spacer width=16 height=1>What happens when an exception occurs in an
exception handler? The original exception that was
caught is officially handled when the exception handler
begins executing. So exceptions occurring in an <br>
</page>
<page>
exception handler need to be processed outside the <b>try</b>
block in which the original exception was thrown.<br>
<spacer width=16 height=1>Exception handlers can be written in a variety of ways.
They could take a closer look at an error and decide to
call <b>terminate</b>. They could <i>rethrow</i> an exception
(<a href="#s8p0">Section 13.8</a>). They could convert one type of
exception into another by throwing a different
exception. They could perform any necessary recovery
and resume execution after the last exception handler.
<a href="^Engineer::c:s0p16"><img src="bckgrnds/icons/seo_ico.gif" align=sidebar></a>They could look at the situation causing the error,
remove the cause of the error and retry by calling the
original function that caused an exception (this would <br>
</page>
<page>
not create infinite recursion). They could return some
status value to their environment, etc.<br>
<spacer width=16 height=1>When a <b>try</b> block does not <b>throw</b> any exceptions and
the <b>try</b> block completes normal execution, control
passes to the first statement after the last <b>catch</b> handler
following the <b>try</b> block.<br>
<spacer width=16 height=1><a href="^Errors::c:s0p14"><img src="bckgrnds/icons/cpe_ico.gif" align=sidebar></a>It is not possible to return to the <b>throw</b> point by issuing
a <b>return</b> statement in a <b>catch</b> handler. Such a <b>return</b>
simply returns to the function that called the function
<a href="^Engineer::c:s0p13"><img src="bckgrnds/icons/seo_ico.gif" align=sidebar></a>containing the <b>catch</b> block.<br>
<spacer width=16 height=1>When an exception is caught, it is possible that
resources may have been allocated but not yet released
in the <b>try</b> block. The <b>catch</b> handler, if possible, should <br>
</page>
<page>
release these resources. For example, the <b>catch</b> handler
should <b>delete</b> space allocated by <b>new</b> and should close
any files opened in the <b>try</b> block that threw the
exception. <br>
<spacer width=16 height=1>A <b>catch</b> block can process the error in a manner that
enables the program to continue executing correctly. Or
the <b>catch</b> block can terminate the program.<br>
<spacer width=16 height=1>A <b>catch</b> handler itself can discover an error and <b>throw</b>
an exception. <a href="^Errors::c:s0p15"><img src="bckgrnds/icons/cpe_ico.gif" align=sidebar></a>Such an exception will not be processed
by <b>catch</b> handlers associated with the same <b>try</b> block as
the <b>catch</b> handler throwing the exception. Rather the
thrown exception will be caught, if possible, by a <b>catch</b>
handler associated with the next outer <b>try</b> block.<br>
After a catch block finishes executing, the statement after the last catch block of the try/catch sequence executes. <br>
<component type="checkbox" width=20 height=18 label="" name="" feedback="False. The catch block specifying a base class type will catch both base class objects and derived class objects.">
A catch block specifying a base class type will not catch a derived class exception object. <br>
<component type=button name=b label="Check Your Answer" width=125 height=24>
</page>
</section>
<section type=Body name=Default title="13.8 Rethrowing an Exception">
<page>
<font size=18 bold>13.8 Rethrowing an Exception</font><hr>
It is possible that the handler that catches an exception
may decide that it cannot process the exception or it
may simply want to release resources before letting
someone else handle it. In this case, the handler can
simply rethrow the exception with the statement<br>
<font size=2><br></font><font size=11><pre>
throw;<p>
</pre></font>
<a href="^Errors::c:s0p17"><img src="bckgrnds/icons/cpe_ico.gif" align=sidebar></a>Such a <b>throw</b> with no arguments rethrows the
exception. If no exception was thrown to begin with,
then the rethrow causes a call to <b>terminate</b>. <br>
<spacer width=16 height=1><a href="^Engineer::c:s0p17"><img src="bckgrnds/icons/seo_ico.gif" align=sidebar></a>Even if a handler can process an exception, and
regardless of whether it does any processing on that <br>
</page>
<page>
exception, the handler can still rethrow the exception
for further processing outside the handler.<br>
<spacer width=16 height=1>A rethrown exception is detected by the next enclosing
<b>try</b> block and is handled by an exception handler listed
after that enclosing <b>try</b> block.<br>
<spacer width=16 height=1>The program of <a href="^Code::c:s0p1"><img src="bckgrnds/icons/code_ico.gif" align=sidebar>Fig. 13.2</a> demonstrates rethrowing an
exception. In the <b>try</b> block at line 26 of <b>main</b>, function
<b>throwException</b> is called. In the <b>try</b> block of function
<b>throwException</b>, the <b>throw</b> statement at line 13
<b>throw</b>s an instance of standard library class <b>exception</b>
(defined in header file <tt><b><exception></b></tt>). This exception is
caught immediately in the <b>catch</b> handler at line 15
which prints an error message then rethrows the <br>
</page>
<page>
exception. This terminates function <b>throwException</b>
and returns control to the <b>try<tt>/catch</tt></b> block in <b>main</b>. The
An <i>exception specification</i> enables a list of exceptions
that can be thrown by a function to be specified.<br>
<font size=2><br></font><font size=11><pre>
int g( float h ) throw ( a, b, c )<p>
{<p>
// function body<p>
}<p>
</pre></font>
It is possible to restrict the exception types thrown from
a function. The exception types are specified in the
function declaration as an <i>exception specification</i> (also
called a <b>throw</b> list). The exception specification lists
the exceptions that may be thrown. A function may
<b>throw</b> the indicated exceptions or derived types. <br>
</page>
<page>
Despite this supposed guarantee that other exception
types will not be thrown, it is possible to do so. If an
exception not listed in the exception specification is
thrown, function <b>unexpected</b> is called. <br>
<spacer width=16 height=1>Placing <b>throw()</b> (i.e., an <i>empty exception specification</i>)
after a function's parameter list states that the function
will not <b>throw</b> any exceptions. Such a function could,
in fact, <b>throw</b> an <b><a href="^Errors::c:s0p18"><img src="bckgrnds/icons/cpe_ico.gif" align=sidebar></a></b>exception; this, too, would generate a
call to <b>unexpected</b>.<br>
<spacer width=16 height=1>A function with no exception specification can <b>throw</b>
any exception. <br>
<font size=2><br></font><font size=11><pre>
void g(); // this function can throw any exception<p>
</pre></font>
</page>
<page>
The meaning of the <b>unexpected</b> function can be
redefined by calling function <b>set_unexpected</b>.<br>
<spacer width=16 height=1>One interesting aspect of exception handling is that the
compiler will not consider it a syntax error if a function
contains a <b>throw</b> expression for an exception not listed
in the function's exception specification. The function
must attempt to <b>throw</b> that exception at execution time
before the error will be caught.<br>
<spacer width=16 height=1>If a function <b>throw</b>s an exception of a particular class
type, that function can also <b>throw</b> exceptions of all
classes derived from that class with <b>public</b> inheritance.<br>
particular scope, the function-call stack is unwound and
an attempt is made to <b>catch</b> the exception in the next
outer <b>try</b>/<b>catch</b> block. Unwinding the function-call
stack means that the function in which the exception
was not caught terminates, all local variables in that
function are destroyed and control returns to the point at
which that function was called. If that point in the
program is in a <b>try</b> block, an attempt is made to <b>catch</b>
the exception. If that point in the program is not in a <b>try</b>
block or the exception is not caught, stack unwinding <br>
</page>
<page>
occurs again. As mentioned in the previous section, if
the exception is not caught in the program, function
<b>terminate</b> is called to terminate the program. The
program of <a href="^Code::c:s0p2"><img src="bckgrnds/icons/code_ico.gif" align=sidebar>Fig. 13.3</a> demonstrates stack unwinding.<br>
<spacer width=16 height=1>In <b>main</b>, the <b>try</b> block at line 25 calls <b>function1</b>. Next,
<b>function1</b> (defined at line 18) calls <b>function2</b>. Then,
<b>function2</b> (defined at line 13) calls <b>function3</b>. Line 10
of <b>function3</b> <b>throw</b>s an <b>exception</b> object. Because line
10 is not in a <b>try</b> block, stack unwinding occurs--
<b>function3</b> terminates and control returns to <b>function2</b>
at line 15. Because line 15 is not in a <b>try</b> block, stack
unwinding occurs again--<b>function2</b> terminates and
control returns to <b>function1</b> at line 20. Because line 20 <br>
</page>
<page>
is not in a <b>try</b> block, stack unwinding occurs one more
time--<b>function1</b> terminates and control returns to
<b>main</b> at line 26. Because line 26 is in a <b>try</b> block, the
<b>exception</b> can be caught and processed in the first
matching <b>catch</b> handler after the <b>try</b> block (at line 28).<br>
</page>
</section>
<section type=Body name=Default title="13.12 Constructors, Destructors and Exception Handling">
<page>
<font size=18 bold>13.12 Constructors, Destructors and Exception Handling</font><hr>
First, let us deal with an issue we have mentioned, but
that has yet to be satisfactorily resolved. What happens
when an error is detected in a constructor? For example,
how should a <b>String</b> constructor respond when <b>new</b>
fails and indicates that it was unable to obtain the space
needed to hold the <b>String</b>'s internal representation? The
problem is that a constructor cannot return a value, so
how do we let the outside world know that the object
has not been properly constructed? One scheme was
simply to return the improperly constructed object and <br>
</page>
<page>
hope that anyone using the object would make
appropriate tests to determine that the object was in fact
bad. Another scheme is to set some variable outside the
constructor. A thrown exception passes to the outside
world the information about the failed constructor and
the responsibility to deal with the failure.<br>
<spacer width=16 height=1>To <b>catch</b> an exception, the exception handler must have
access to a copy constructor for the thrown object
(default memberwise copy is also valid). <br>
<spacer width=16 height=1>Exceptions thrown in constructors cause destructors to
be called for any objects built as part of the object being
constructed before the exception is thrown.<br>
</page>
<page>
Destructors are called for every automatic object
constructed in a <b>try</b> block before an exception is
thrown. An exception is handled at the moment the
handler begins executing; stack unwinding is
guaranteed to have been completed at that point. If a
destructor invoked as a result of stack unwinding
<b>throw</b>s an exception, <b>terminate</b> is called.<br>
<spacer width=16 height=1>If an object has member objects and if an exception is
thrown before the outer object is fully constructed, then
destructors will be executed for the member objects that
have been constructed prior to the occurrence of the
exception.<br>
</page>
<page>
If an array of objects has been partially constructed
when an exception occurs, only the destructors for the
constructed array elements will be called.<br>
<spacer width=16 height=1>An exception could preclude the operation of code that
would normally release a resource, thus causing a
<i>resource leak</i>. One technique to resolve this problem is
to initialize a local object when the resource is acquired.
When an exception occurs, the destructor will be
invoked and can free the resource.<br>
<spacer width=16 height=1>It is possible to <b>catch</b> exceptions thrown from
destructors by enclosing the function that calls the
destructor in a <b>try</b> block and provide a <b>catch</b> handler
with the proper type. The thrown object's destructor <br>
</page>
<page>
executes after an exception handler completes
execution.<br>
</page>
<page>
<b>Select the true statement(s). </b><br>
<component type="checkbox" width=20 height=18 label="" name="" feedback="False. Destructors are called for every automatic object constructed in a try block before the exception is thrown.">
Destructors are not called for every automatic object constructed in a try block before the exception is thrown. <br>
Exceptions thrown in constructors cause destructors to be called for any object built as part of the constructor call before the exception is thrown. <br>
<component type=button name=b label="Check Your Answer" width=125 height=24>
</page>
</section>
<section type=Body name=Default title="13.13 Exceptions and Inheritance">
<page>
<font size=18 bold>13.13 Exceptions and Inheritance</font><hr>
Various exception classes can be derived from a
common <a href="^Debug::c:s0p2"><img src="bckgrnds/icons/dbt_ico.gif" align=sidebar></a>base class. If a <b>catch</b> catches a pointer or
reference to an exception object of a base-class type, it
can also <b>catch</b> a pointer or reference to all objects of
classes derived from that base class. This can allow for
polymorphic processing of related errors.<br>
</page>
</section>
<section type=Body name=Default title="13.14 Processing new Failures">
because a <b>double</b> is normally 8 bytes). If <b>new</b> fails and
<b>throw</b>s a <b>bad_alloc</b> exception, the loop terminates and
the program continues in the exception-handling flow
of control at line 18 where the exception is caught and
processed. The message <tt><b>"Exception occurred: "</b></tt> is
printed followed by <b>exception.what()</b> which returns a
string with an exception-specific message (<tt><b>"Allocation
Failure"</b></tt> in the case of <b>bad_alloc</b>). The output shows <br>
</page>
<page>
that only three iterations of the loop were performed
before <b>new</b> failed and threw the <b>bad_alloc</b> exception.
Your output may differ based on the physical memory
and disk space available for virtual memory on your
system. <br>
<spacer width=16 height=1>Compilers vary in the way they support <tt><b>new</b></tt> failure
handling. In general, many current and older C++
compilers return <b>0</b> by default when <b>new</b> fails. Some of
these compilers support new throwing an exception if
the header file <b><new></b> (or <tt><b><new.h></b></tt>) is included. Other
compilers--such as CodeWarrior Professional Release
1--<b>throw bad_alloc </b>by default whether or not you
include header file <b><new></b>. Read the documentation for <br>
</page>
<page>
your compiler to determine your compiler's support for
<b>new</b> failure handling.<br>
<spacer width=16 height=1><a href="^Engineer::c:s0p18"><img src="bckgrnds/icons/seo_ico.gif" align=sidebar></a>The ANSI/ISO C++ draft standard specifies that
standard-compliant compilers can still use a version of
<b>new</b> that returns <b>0</b> when it fails. For this purpose, the
header file <b><new></b> defines the type <b>nothrow</b> that is
ANSI/ISO draft standard C++ specifies that when new fails, it should throw a bad_alloc exception. <br>
<component type="checkbox" width=20 height=18 label="" name="" feedback="False. Once a new handler is registered in the program with set_new_handler new will not throw a bad_alloc on failure.">
Once a new handler is registered in the program with set_new_handler, new will throw a bad_alloc on failure. <br>
<component type=button name=b label="Check Your Answer" width=125 height=24>
</page>
</section>
<section type=Body name=Default title="13.15 Class auto_ptr and Dynamic Memory Allocation">
<page>
<font size=18 bold>13.15 Class <b>auto_ptr</b> and Dynamic Memory
Allocation</font><hr>
A common programming practice is to allocate
dynamic memory (possibly an object) on the free store,
assign the address of that memory to a pointer, use the
pointer to manipulate the memory and deallocate the
memory with <b>delete</b> when the memory is no longer
needed. If an exception occurs after the memory has
been allocated and before the <b>delete</b> statement is
executed, a memory leak could occur. The ANSI/ISO
C++ draft standard provides class template <b>auto_ptr</b> in
header file <tt><b><memory></b></tt> to deal with this situation. <br>
</page>
<page>
An object of class <b>auto_ptr</b> maintains a pointer to
dynamically allocated memory. When an <b>auto_ptr</b>
object goes out of scope, it performs a <b>delete</b> operation
on its pointer data member. Class template <b>auto_ptr</b>
provides operators <b>*</b> and <b>-></b> so an <b>auto_ptr</b> object can
be used like a regular pointer variable.<a href="^Code::c:s0p6"> <img src="bckgrnds/icons/code_ico.gif" align=sidebar>Figure 13.7</a>
demonstrates an <b>auto_ptr</b> object that points to an object
of class <b>Integer</b> (defined at lines 818). <br>
<spacer width=16 height=1>Line 25<br>
<font size=2><br></font><font size=11><pre>
auto_ptr< Integer > ptrToInteger( new Integer( 7 ) );<p>
</pre></font>
</page>
<page>
creates <b>auto_ptr</b> object <b>ptrToInteger</b> and initializes it
with a pointer to a dynamically allocated <b>Integer</b> object
containing the value 7. <br>
<spacer width=16 height=1>Line 28<br>
<font size=2><br></font><font size=11><pre>
ptrToInteger->setInteger( 99 ); <p>
</pre></font>
uses the <b>auto_ptr</b> overloaded <b>-></b> operator and the
function call operator <b>() </b>to call function <b>setInteger</b> on
the <b>Integer</b> object pointed to by <b>ptrToInteger</b>.<br>
<spacer width=16 height=1>The call<br>
<font size=2><br></font><font size=11><pre>
( *ptrToInteger ).getInteger()<p>
</pre></font>
in line 30 uses the <b>auto_ptr</b> overloaded <b>*</b> operator to
dereference <b>ptrToInteger</b> then uses the dot (<b>.</b>) operator <br>
</page>
<page>
and the function call operator <b>()</b> to call function
<b>getInteger</b> on the <b>Integer</b> object pointer to by
<b>ptrToInteger</b>.<br>
<spacer width=16 height=1>Because <b>ptrToInteger</b> is a local automatic variable in
<b>main</b>, <b>ptrToInteger</b> is destroyed when <b>main</b>
terminates. This forces a <b>delete</b> of the <b>Integer</b> object
pointed to by <b>ptrToInteger</b> which, of course, forces a
call to the <b>Integer</b> class destructor. Most importantly,
Class template auto_ptr provides operators -> and *. <br>
<component type="checkbox" width=20 height=18 label="" name="" feedback="False. A delete operation will automatically be performed on the object to which the points.">
When an auto_ptr goes out of scope, it will not perform a delete operation.auto_ptr <br>
<component type=button name=b label="Check Your Answer" width=125 height=24>
</page>
</section>
<section type=Body name=Default title="13.16 Standard Library Exception Hierarchy">
<page>
<font size=18 bold>13.16 Standard Library Exception Hierarchy</font><hr>
Experience has shown that exceptions fall nicely into a
number of categories. The C++ draft standard includes
a hi<a href="^Engineer::c:s0p19"><img src="bckgrnds/icons/seo_ico.gif" align=sidebar></a>erarchy of exception classes. This hierarchy is
headed by base class <b>exception</b> (defined in header file
<b><exception></b>) which offers the service <b>what()</b> that is
overridden in each derived class to issue an appropriate
error message.<br>
<spacer width=16 height=1>From base class <b>exception</b>, some of the immediate
derived classes are <b>runtime_error</b> and <b>logic_error</b>
(both defined in header <tt><b><stdexcept></b></tt>), each of which
has several derived classes.<br>
</page>
<page>
<a href="^Errors::c:s0p19"><img src="bckgrnds/icons/cpe_ico.gif" align=sidebar></a>Also derived from <b>exception</b> are the exceptions thrown
by C++ language features--for example, <b>bad_alloc</b> is
thrown by <b>new</b> (<a href="#s14p0">Section 13.14</a>), <b>bad_cast</b> is thrown by
<b>dynamic_cast</b> (Chapter 21) and <b>bad_typeid</b> is thrown
by <b>typeid</b> (Chapter 21). By including
<tt><b>std::bad_exception</b></tt> in the <b>throw</b> list of a function, if
an unexpected exception occurs, <b>unexpected()</b> will
throw <b>bad_exception</b> instead of terminating (by
default) or instead of calling another function specified
with <b>set_unexpected</b>.<br>
<spacer width=16 height=1>Class <b>logic_error</b> is the base class of several standard
exception classes that indicate errors in program logic
that can normally be prevented by writing proper code. <br>
</page>
<page>
Descriptions of some of these classes follow. Class
<b>invalid_argument</b> indicates that an invalid argument
was passed to a function (proper coding can, of course,
prevent invalid arguments from reaching a function).
Class <b>length_error</b> indicates that a length larger than
the maximum size allowed for the object being
manipulated was used for that object (we throw
<b>length_errors</b> in Chapter 19 when we deal with
<b>string</b>s). Class <b>out_of_range</b> indicates that a value
such as a subscript into an array or <b>string</b> was out of
range. <br>
<spacer width=16 height=1>Class <b>runtime_error</b> is the base class of several other
standard exception classes that indicate errors in a <br>
</page>
<page>
program that can only be detected at execution time.
Class <b>overflow_error</b> indicates that an arithmetic
overflow error occurred. Class <b>underflow_error</b>
<indent width=8 delay>* Exception handlers are contained in <b>catch</b> blocks.
Each <b>catch</b> block starts with the keyword <b>catch</b> followed by parentheses containing a type and an optional
parameter name. This is followed by braces delineating
the exception-handling code. When an exception is
caught, the code in the <b>catch</b> block is executed.</indent>
<indent width=8 delay>* The <b>catch</b> handler defines its own scope. </indent>
<indent width=8 delay>* The parameter in a <b>catch</b> handler can be named or
unnamed. If the parameter is named, the parameter can
be referenced in the handler. If the parameter is
unnamed, i.e., only a type is listed for the purpose of
matching with the thrown object type or an ellipsis for </indent>
</page>
<page>
<indent width=8 delay>* all types, then the handler will ignore the thrown object.
The handler may rethrow the object to an outer <b>try</b>
block. </indent>
<indent width=8 delay>* It is possible to specify customized behavior to
replace function <b>terminate</b> by designating another
function to be executed and providing that function's
name as the argument in a <b>set_terminate</b> function call.</indent>
<indent width=8 delay>* <b>catch(...)</b> means to <b>catch</b> all exceptions.</indent>
<indent width=8 delay>* It is possible that no handler will match a particular
thrown object. This causes the search for a match to
continue in an enclosing <b>try</b> block.</indent>
<indent width=8 delay>* The exception handlers are searched in order for an
appropriate match. The first handler that yields a match </indent>
</page>
<page>
<indent width=8 delay>* is executed. When that handler finishes executing, control resumes with the first statement after the last <b>catch</b>
block.</indent>
<indent width=8 delay>* The order of the exception handlers affects how an
exception is handled.</indent>
<indent width=8 delay>* A derived-class object can be caught either by a handler specifying the derived-class type or by handlers
specifying the types of any base classes of that derived
class.</indent>
<indent width=8 delay>* Sometimes a program may process many closely
related types of exceptions. Instead of providing separate exception classes and <b>catch</b> handlers for each, a
programmer can provide a single exception class and </indent>
</page>
<page>
<indent width=8 delay>* <b>catch</b> handler for a group of exceptions. As each exception occurs, the exception object can be created with
different <b>private</b> data. The <b>catch</b> handler can examine
this <b>private</b> data to distinguish the type of the exception.</indent>
<indent width=8 delay>* It is possible that even though a precise match is
available, a match requiring standard conversions will
be made because that handler appears before the one
that would result in a precise match. </indent>
<indent width=8 delay>* By default, if no handler is found for an exception,
the program terminates. </indent>
<indent width=8 delay>* An exception handler cannot directly access variables in the scope of its <b>try</b> block. Information the han</indent>
</page>
<page>
<indent width=8 delay>* dler needs is normally passed in the thrown object.</indent>
<indent width=8 delay>* Exception handlers can take a closer look at an error
and decide to call <b>terminate</b>. They can rethrow an
exception. They can convert one type of exception into
another by throwing a different exception. They can
perform any necessary recovery and resume execution
after the last exception handler. They can look at the situation causing the error, remove the cause of the error,
and retry by calling the original function that caused an
exception (this would not create infinite recursion).
They can simply return some status value to their environment, etc.</indent>
<indent width=8 delay>* A handler that catches a derived-class object should </indent>
</page>
<page>
<indent width=8 delay>* be placed before a handler that catches a base-class
object. If the base-class handler were first, it would
catch both the base-class objects and the object of
classes derived from that base class.</indent>
<indent width=8 delay>* When an exception is caught, it is possible that
resources may have been allocated but not yet released
in the <b>try</b> block. The <b>catch</b> handler should release these
resources. </indent>
<indent width=8 delay>* It is possible that the handler that <b>catch</b>es an exception may decide that it cannot process the exception. In
this case, the handler can simply rethrow the exception.
A <b>throw</b> with no arguments rethrows the exception. If
no exception was thrown to begin with, then the </indent>
</page>
<page>
<indent width=8 delay>* rethrow causes a call to <b>terminate</b>.</indent>
<indent width=8 delay>* Even if a handler can process an exception, and
regardless of whether it does any processing on that
exception, the handler can rethrow the exception for
further processing outside the handler. A rethrown
exception is detected by the next enclosing <b>try</b> block
and is handled by an exception handler listed after that
enclosing <b>try</b> block.</indent>
<indent width=8 delay>* A function with no exception specification can
<b>throw</b> any exception.</indent>
<indent width=8 delay>* Function <b>unexpected</b> calls a function specified with
function <b>set_unexpected</b>. If no function has been specified in this manner, <b>terminate</b> is called by default.</indent>
</page>
<page>
<indent width=8 delay>* Function <b>terminate</b> can be called in various ways:
explicitly; if a thrown exception cannot be caught; if the
stack is corrupted during exception handling; as the
default action on a call to <b>unexpected</b>; or if during
stack unwinding initiated by an exception, an attempt
by a destructor to <b>throw</b> an exception causes <b>terminate</b>
to be called.</indent>
<indent width=8 delay>* Prototypes for functions <b>set_terminate</b> and
<b>set_unexpected</b> are found in header files <b><terminate.h></b> and <b><unexpected.h></b>, respectively.</indent>
<indent width=8 delay>* Functions <b>set_terminate</b> and <b>set_unexpected</b> return
pointers to the last function called, by <b>terminate</b> and
<b>unexpected</b>. This enables the programmer to save the </indent>
</page>
<page>
<indent width=8 delay>* function pointer so it can be restored later.</indent>
<indent width=8 delay>* Functions <b>set_terminate</b> and <b>set_unexpected</b> take
pointers to functions as arguments. Each argument must
point to a function with <b>void</b> return type and no arguments.</indent>
<indent width=8 delay>* If the last action of a user-defined termination function is not to exit a program, function <b>abort</b> will automatically be called to end program execution after the
other statements of the user-defined termination function are executed.</indent>
<indent width=8 delay>* An exception thrown outside a <b>try</b> block will cause
the program to terminate.</indent>
<indent width=8 delay>* If a handler cannot be found after a <b>try</b> block, stack </indent>
</page>
<page>
<indent width=8 delay>* unwinding continues until an appropriate handler is
found. If a handler is ultimately not found, then <b>terminate</b> is called which by default aborts the program with
<b>abort</b>.</indent>
<indent width=8 delay>* Exception specifications list the exceptions that may
be thrown from a function. A function may <b>throw</b> the
indicated exceptions, or it may <b>throw</b> derived types. If
an exception not listed in the exception specification is
thrown, <b>unexpected</b> is called. </indent>
<indent width=8 delay>* If a function <b>throw</b>s an exception of a particular class
type, that function can also <b>throw</b> exceptions of all
classes derived from that class with <b>public</b> inheritance.</indent>
<indent width=8 delay>* To <b>catch</b> an exception, the exception handler must </indent>
</page>
<page>
<indent width=8 delay>* have access to a copy constructor for the thrown object.</indent>
<indent width=8 delay>* Exceptions thrown from constructors cause destructors to be called for all completed base-class objects and
member objects of the object being constructed before
the exception is thrown. </indent>
<indent width=8 delay>* If an array of objects has been partially constructed
when an exception occurs, only the destructors for the
constructed array elements will be called.</indent>
<indent width=8 delay>* Exceptions thrown from destructors can be caught by
enclosing the function that calls the destructor in a <b>try</b>
block and provide a <b>catch</b> handler with the proper type.</indent>
<indent width=8 delay>* A powerful reason for using inheritance with exceptions is for creating the ability to <b>catch</b> a variety of </indent>
</page>
<page>
<indent width=8 delay>* related errors easily with concise notation. One could
certainly <b>catch</b> each type of derived-class exception
object individually, but it is much more concise to simply catch the base-class exception object. </indent>
<indent width=8 delay>* The ANSI/ISO C++ draft standard specifies that
when <b>new</b> fails, it <b>throw</b>s a <b>bad_alloc</b> exception
(<b>bad_alloc</b> is defined in header file <b><new></b>). </indent>
<indent width=8 delay>* Many compilers are not current with the ANSI/ISO
C++ draft standard and still use the version of <b>new</b> that
returns <b>0</b> on failure. </indent>
<indent width=8 delay>* Function <b>set_new_handler</b> (prototyped in header
file <b><new></b> or <b><new.h></b>) takes as its argument a function pointer for a function that takes no arguments and </indent>
</page>
<page>
<indent width=8 delay>* returns <b>void</b>. The function pointer is registered as the
function to call when <b>new</b> fails. Once a <b><i>new handler</i></b> is
registered with <b>set_new_handler</b>, new will not throw
<b>bad_alloc</b> on failure.</indent>
<indent width=8 delay>* An object of class <b>auto_ptr</b> maintains a pointer to
dynamically allocated memory. When an <b>auto_ptr</b>
object goes out of scope, it automatically performs a
<b>delete</b> operation on its pointer data member. Class template <b>auto_ptr</b> provides operators <b>*</b> and<b> -></b> so an
<b>auto_ptr</b> object can be used like a regular pointer variable.</indent>
<indent width=8 delay>* The C++ draft standard includes a hierarchy of
exception classes headed by base class <b>exception</b> </indent>
</page>
<page>
<indent width=8 delay>* (defined in header file <b><exception></b>) which offers the
service <b>what()</b> that is overridden in each derived class
to issue an appropriate error message.</indent>
<indent width=8 delay>* By including <b>std::bad_exception </b>in the <b>throw</b> list of
